Electronic computer system secured from unauthorized access to and manipulation of data

ABSTRACT

In general, the invention relates to a method for securing a computer system. The method includes monitoring an operating system in the computer system and trapping, in response to the monitoring, a process system call where the process system call originated in a host executing in the computer system. Responsive to the trapping, an isolated user environment (IUE) is created in the computer system. Creating the IUE includes allocating memory and persistent storage for the IUE. In addition, the IUE includes a file system filter driver (FSFD) configured to redirect Input/Output (I/O) calls originating from the IUE to the persistent storage, and a network interface/NDIS hook component configured to control network traffic originating from the IUE and destined for the IUE. The method further includes, after creating the IUE, loading the process system call into the IUE and executing the process system call in the IUE.

The present application claims the benefit of prior filed U.S.Provisional Applications Ser. No. 60/613,768 filed 28 Sep. 2004 and Ser.No. 60/675,613 filed 28 Apr. 2005, to which the present application is aregular U.S. national application, and which prior applications areincorporated herein by reference.

FIELD OF THE INVENTION

The present invention is in the field of support for electricalcomputers and digital processing systems. More specifically, the presentinvention relates to security software and processes for protecting acomputer system's hardware, software and data from malicious causeddestruction, unauthorized modification or unauthorized disclosure.

BACKGROUND OF THE INVENTION

As the online community grows with the development of high bandwidth,high speed, and high availability connectivity to the public internet,we are seeing an ever increasing proliferation of malicious content andidentity/data theft and destruction, perpetrated right in our own homeand office computers. Malignant and poisonous web content administeredthrough ‘data mining’ tools, ‘Add-Ware’ content, activeX, java script,misleading download queries, Trojan content and virus infected data isresponsible for extraordinary, quantifiable, monetary losses to theenterprise every year. There is no measure, however, for the loss offprivacy, intimate data and criminal violations these intrusions preyupon our families. Passive, after ‘the fact’, behindhand screening forTrojan and virus content, such as that provided by modern virus scanningsoftware, has proven itself an inadequate bastion of defense to thecyber theft and data corruption mechanisms rampant in the globalcyberspace. The computer security industry has made attempts to addressthese failings by implementing solutions such as execution protectionproducts that only allow the execution of ‘White-listed’ applications onany given computer; but such products require constant centralizedadministration and customization to fit within a divers enterprisecommunity, and are unreasonable solutions for home users due to theirmanagement needs and lack of transparency. Though restricting executioncan greatly improve the protection of local computer data, a moreflexible solution is to virtualize execution in an isolated environment.This methodology has been proven by software implemented virtualmachines such as those presented by VMWare©. However, such solutions arenot practical, nor were they designed for, implementation as computersecurity software. Such solutions require the full installation of asecondary operating system within each virtual environment. Implementingsuch environments requires a higher level of computer understanding thanthe average user and presents management/administration and storagecomplications to implementations across an enterprise environment. Evensolutions as common to modern computer environments as advancedstatefull firewall protection, host security, and access controlmanagement is beyond the average computer owner, let alone the peers andloved ones sharing their computer space. Microsoft's Windowsarchitecture does not provide inherent user or group isolation robustenough to protect low privileged users from the actions of maliciouscode should it find its way onto their computer, nor the proliferationof damage or theft throughout all the computer's user and administratorspace. Current third party solutions have proven themselves inadequateto protect a computer from the transgressions of its operators ormalicious attack. This begs the questions, is it possible to split aWindows computer into secure virtual environments with as much isolationas possible between each one, looking like individual computers withoutthe cumbersome implementation of classic virtual machine environments?To isolate disk space, virtualize execution, make user data inaccessibleand unreadable to other users; yet share some/most/all common tasks(monitoring, backup, ups, hardware configuration and libraries etc) andstill allow the individual evolution of each virtual environment? Canthis be done transparently, unobtrusively?

SUMMARY OF THE INVENTION

The present invention is software for use with a PC-type computer,either standing alone or connected to a network. The present inventivesoftware, when used in conjunction with a typical PC-type computer,prevents the unauthorized export of data from the computer,corruption/loss of data due to malware or local action. This protectionfrom the unauthorized export of data is accomplished by running thepresent Isolated/Secure User Environment Software (IUE/SUEZ) as aprocess component of the computer system. The SUEZ application providesa bubble from which a user can operate the computer, access all of thecomputer's applications and freely brows the Internet, but not have anyof the computer systems files accessed for export by a trojan or likemalicious code. The result of providing a SUEZ enhanced computer systemis that, malicious code from an external data source, such as a filedownloaded from the Internet or imported from an external data source,cannot steal data or eves-drop on a SUEZ user on the computer.

The present invention is a secured Windows OS electronic computer systemhaving a software based isolated User environment protected fromunauthorized access to and manipulation of data on the system. Thesoftware of the present invention on a Windows® OS computer systemimplements an isolated User file system and provides process/IPCisolation, Windows® registry isolation, network interface isolation, andisolated administrative control on the computer system. Interactivecomponents of the system include an execution hook component, a jobobject component, a system call hook component, a file system blockdevice driver, a file system/filter driver, a network interface/NDIShook component, and an environment handler.

The execution hook component traps system calls requesting processexecution. It also initiates creation of the isolated User environment(IUE) and manages assignment of successive process execution requests tothe appropriate method of execution. To provide appropriate isolatedprocess execution control, the execution hook traps all calls to load anexecutable image and tests them for an assigned User context. Allexecution requests without a User context are either assigning anadministrative context and passed on for processing in the manner nativeto a Host computer system or assigning a User context by interrogatingthe environment handler for User authentication and credentials etc.Additionally, the execution hook is responsible for triggering requeststo the environment handler, upon new User context assignments, to createa new User environment. New User environments include an isolated filesystem, network connection, Windows registry hive and executionenvironment. The current requested process and all subsequent processeswith User context are bound to this environment. Trapped processexecution requests with existing User context are assigned to theirassociated User specific job object. All filtering done by the executionhook is based on metadata described by the software and environmenthandler.

The job object component is responsible for creating, destructing,managing and manipulating job objects. It provides an alternativeprocess creation mechanism to that native to the Host computer system bystarting User processes in a restricted state. Additionally, itimplements User credential based security descriptors that define therestrictions of User processes and provides isolated process/IPC andmemory control. All based on appropriate metadata described by thesoftware and the environment handler.

The system call hook component traps and filters all Windows registryI/O requests. This facilitates file system and memory isolation byfiltering calls based on their User context and redirecting Userregistry I/O requests to the User's isolated file system. The systemcall hook processes User specific credentials, prescribed by theenvironment handler, to define what registry hives or keys or subsetthereof will be abstracted from Host computer systems native registry.All filtering is done based on appropriate metadata described by thesoftware and environment handler.

The file system block device driver component is responsible formounting and unmounting the isolated User file system. This facilitatesisolating the file system from the Host computers file system namespace.

The file system filter driver component filters all file system I/Orequests to accomplish isolation of the User file system. The driverredirects file system I/O requests associated with a User context tothat User's isolated file system. By providing granular proxy of allfile system I/O, the file system filter driver facilitates theredirection of all or some subset of I/O based on request type,requested file system and object credentials or type. All filtering isdone based on appropriate metadata described by the software andenvironment handler.

The network interface/NDIS hook component is responsible for abstractingthe User's network interface from the Host computer system's networkinterface. Additionally, it provides bridging, packet filtering andother services typical of network interface control. All filtering doneby the NDIS driver is based on metadata described by the software andenvironment handler.

The environment handler provides environment management services for allthe software components making up the IUE. It reveals an administrativeconfiguration interface allowing the definition of rules and generalconfiguration data. The environment handler also managing and definesUser authentication and credentials for all the IUE software components.This includes prescribing filter metadata and periodically obtaining logstatistics from the software components as well as revealing othercontrols typical of software management systems.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a general interconnect scheme for certaininternal components of a typical computer and its connection to theInternet.

FIG. 2 is a block diagram depicting the configuration of a typicalPC-type computer upon installation of an application comprising thepresent Secure User Environment Software (SUEZ) onto a PC-type computersystem of FIG. 1.

FIG. 3 is a block diagram depicting the Ready State configuration of thecomputer upon the trapping of the first process execution call after itsinitial activation on the computer.

FIG. 4A is a block diagram depicting an Active State configuration ofthe computer of FIG. 3 at a point after a first trigger has beendetected and a proper “context” has been assigned or recognized for atriggering execution call, but before the associated thread has beenpassed to the computer's CPU.

FIG. 4B is a block diagram depicting an Active State configuration ofthe computer at a point after that of FIG. 5A, at which point theassociated thread has been passed to the computer's CPU and executed,which has caused certain processes (e.g., a browser application) to beloaded into bubble memory and a connection to be established to certainperipheral devices.

FIG. 4C is a block diagram depicting an Active State configuration ofthe computer at a point after that of FIG. 4B, at which point aconnection to the Internet has been established.

FIG. 5A is a block diagram depicting a configuration of the computerrunning the present SUEZ at a point after that of FIG. 4B, at whichpoint additional process are loaded into bubble memory, which processesare derived from an external data source such as the Internet and someportion of which may be saved to bubble storage.

FIG. 5B is a block diagram depicting a configuration of the computerrunning the present SUEZ at a point where the downloaded modules inbubble memory are attempting to write, but all write calls originatingin bubble memory can only be sent to bubble storage.

FIG. 5C is a block diagram depicting a configuration of the computerrunning the present SUEZ at a point in the shut-down process where theuser has logged-off, causing the connection to the Internet to close andbubble memory to be killed. However, any write call executed during thesession to bubble storage remains isolated in bubble storage, unlessotherwise deleted, e.g., by a “clean-up” function.

FIG. 5D is a block diagram depicting a configuration of the computerrunning the present SUEZ at a point in the shut-down process where theSUEZ data storage space (bubble storage) is unmounted and appears to theoperating system to be configured as a single encrypted flat file storedon a data storage device.

FIG. 6 is a block diagram similar to FIG. 4C, but depicting an ActiveState configuration of the computer on a subsequent initiation of theSUEZ environment. In this configuration, when the stored SUEZ data spaceis mounted, it contains the data written to it in previous SUEZsessions, and illustrates the persistence of certain data created in theprevious SUEZ session.

FIG. 7A is a block diagram depicting a configuration of the computerrunning the present SUEZ at a point in the active state where a modulecontaining a trojan has been downloaded into bubble memory and copiedinto bubble storage (the SUEZ data storage space) prior to itsexecution.

FIG. 7B is a block diagram depicting a configuration of the computerrunning the present SUEZ at a point in the active state where a file inbubble storage containing a trojan is called from bubble storage andexecuted in bubble memory. On execution, the trojan attempts to write toa primary system file (e.g., the system registry), but instead is causedby the SUEZ application to be written to the storage bubble.

FIG. 7C is a block diagram depicting a configuration of the computerrunning the present SUEZ at a point in the shut-down process where theuser has logged-off, causing the connection to the Internet to close andbubble memory to be killed. However, any writing executed during thesession to bubble storage remains isolated in bubble storage, unlessotherwise deleted as shown, e.g., by a “clean-up” function.

FIG. 7D is a block diagram depicting an Active State configuration ofthe computer at a point on boot-up after a SUEZ session as depicted inFIG. 7C has been previously run on the computer. In this case, whenbubble storage is mounted, it contains the data written to it inprevious SUEZ sessions, including the trojan file (unless the file wasidentified as malicious and eliminated by the cleanup function at theclose of the prior SUEZ session). However, because the malicious filescreated by the trojan were isolated in bubble storage where they werenot executed by a reboot or upon mounting of bubble storage.

FIG. 8 is a block diagram illustrating an overview of the relationshipof the various software and data components of the SUEZ system.

FIG. 9 is a block diagram of the relationship between the Execute Hookmodule and the other modules of the SUEZ software application.

FIG. 10 is a block diagram of the relationship between the Job ObjectManager module and the other modules of the SUEZ software application.

FIG. 11 is a block diagram of the relationship between theAuthentication Services module and the other modules of the SUEZsoftware application.

FIG. 12 is a block diagram of the relationship between the EnvironmentHandler module and the other modules of the SUEZ software application.

FIG. 13 is a block diagram of the relationship of the File System FilterDriver to the operating system and its native file system driver.

FIG. 14 is a block diagram of the relationship of the NDIS Hook driverto the operating system and its native NDIS driver.

FIG. 15 is a block diagram of the relationship of the System Call Hookto the operating system and its native system call handler.

FIG. 16 is a high level flow chart diagramming the major components theisolated User environment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

The following detailed description presents an embodiment of theinvention providing isolation of a User (User being the computeroperator bound by the conditions of the preferred embodiment)environment to the extent that all User interactions with the computersystem, including process execution, interprocess communication (IPC),file system I/O (input/output), Windows registry I/O and network I/O areisolated from the hosting computer systems operating environment(referred to below as Host), in such a way as to protect Host from Usertransgressions, such as maliciously caused destruction, unauthorizedmodification, or unauthorized disclosure of data.

The preferred embodiment will be described with reference to theaccompanying drawings and broken into 3 sections to better describe thepresent invention. Section one will describe the hardware and Hostcomputer system environment across multiple operating states with thepreferred embodiment implemented. Section two will provide a systemlevel overview of the embodiment. Section three will be a description ofuse cases.

Referring now to the drawings, the details of preferred embodiments ofthe present invention are graphically and schematically illustrated.Like elements in the drawings are represented by like numbers, and anysub-components of the same element are represented by like numbers witha different lower case letter suffix.

Operating States

The description of FIGS. 1 through 7D will provide a comprehensive viewof the preferred embodiment at multiple states of operation on apreferred type computer system and hardware, but is not intended tolimit the applicable environments. One of ordinary skill in the art willrecognize that the present invention can be implemented with theaccompaniment of other electrical computer system configurations; multiprocessor systems, main frame computers, hand held devices, consumerelectronics and embedded systems are examples of such. One canappreciate that the present invention can also be practiced incombination with remote processing and or data storage, whether over adistributed network or via removable hardware or media directlyinterfacing the hosting computer system.

As shown in FIG. 1, the Internet 14 is typically accessed by a computer20 via an Internet node 16. Depending on the configuration of thecomputer 20, the node 16 represents a device or devices such as a modem,a network card, a router and other interface hardware for connecting thecomputer 20 to a network such as the Internet 14 via an I/O port 22.Other external data sources, such as floppy drives, optical disk drivesand other external data storage devices are also connectable to thecomputer 20 via an I/O port 22 as a peripheral device 40.

Preferable, the computer system 20 can be of any configuration ormanufacture running a Microsoft WINDOWS® operating system (preferablyWINDOWS 2000®, XP® or compatible operating system). These includedesk-tops, lap-tops or other devices having a CPU, storage andconnectivity to an external data source, e.g., the Internet 14. In apreferred simple embodiment as exemplified in FIG. 1, the present systemcomprises a computer 20 to which is connected certain peripheral devices40, such as a keyboard, monitor, and printer (and optionally, to anexternal data storage device) through a number of input/output (I/O)ports 22. Also connected to the computer via an I/O port 22 is anInternet node 16. The node device 16 can be any of a number of suchdevices known in the art and compatible with the configuration of thecomputer 20 to which it is attached to accomplish this purpose, such asmodems, routers, etc. Although the peripheral devices 40 and the node 16are illustrated in the example of FIG. 1 as external to the computer 20,it is intended and is appreciable by one of ordinary skill in the artthat these elements can be incorporated into or share the same housingas the computer 20 to one degree or another. The structure and functionof the other computer components and their connectivity andcommunication interrelationships are typical of the field and known toone of ordinary skill in the art. Control of the Internet node 16 andother peripheral devices 40 is typically accomplished in the usualmanner via the computer 20—to which they are attached. In addition tothe I/O ports 22, the computer 20 comprises the other internal featuresand components typical of a PC, such as a central processing unit (CPU)24, one or more data storage devices 26, volatile memory (e.g., RAM) 28,and other internal features and components 30.

The present Isolated User Environment (IUE or SUEZ) system isinstallable on a typical computer system as illustrated in FIG. 2. FIG.2 depicts the Installation State or the configuration of the computersystem 20 upon installation of the IUE components. In a preferredembodiment, an external data source (not shown) was used to install theIUE components into data storage on a PC type computer 20. Installationof the IUE application caused certain new files or sets of files 100 tobe written to the data storage device (i.e., the internal disk drive) 26of the computer 20. Additionally, installation of the IUE softwarecaused the modification of certain of the computer's pre-existing files116. The combination of these two file sets 100 & 116 comprise the IUEsoftware. In the embodiment illustrated, the installation conditionpersisted in data storage even though the IUE application was notactivated until after the computer's operating system (OS) was rebooted.

The Ready State configuration of the computer occurs on every start-upof the computer 20, i.e., upon every reboot after installation of thepresent IUE software. Starting up the computer once the IUE applicationis installed causes functions or processes to run in memory: a IUEdriver set 300 and a IUE environment (bubble) manager process 340. Adetector function residing in the driver set 300 monitors the operatingsystem for process execution requests to detect and trap the occurrenceof a detector trigger event. The environment manager 340 providesmanagement services for the components of the IUE application, such asuser profile and administration configurations.

In the embodiment illustrated in FIG. 3, the detector trigger event wasa process execution system call. On being triggered, the detectorfunction traps the call checking for the presence of a proper User“context.” The term “context” is a term of art, and as used herein is tobe given its usual meaning as generally known in the field. If a propercontext is found, the call is passed to the Object Manager FIG. 10. If aproper context is not found, the call is passed to the EnvironmentHandler for authentication, see FIG. 12.

FIG. 4A depicts the Active State/Triggered configuration of the computer20, which occurs at a point after a first trigger event has beendetected and a proper context has been either detected for or assignedto the trapped process execution call. In the state depicted, a contextand the IUE bubble are established. The IUE bubble comprises a memoryallocation (bubble memory) 120 and a storage allocation (bubble storage)100 a. Bubble memory 120 is typically an allocation of RAM, and bubblestorage 100 a is typically a flat file mounted as a block device by thedriver set 300. At this point, the triggering process is assigned to thejob object, “loaded suspended” into bubble memory 120, but is not yetpassed to the CPU 24 for execution. For example, in the case of atrigger such as a browser call (e.g., a call to load InternetExplorer®), at this point the browser is loaded into bubble memory 120,but not yet executed, therefore no browser initiated connection has beenmade to the Internet 14.

FIG. 4B is a block diagram depicting an Active State configuration ofthe computer at a point after that of FIG. 4A, at which point theassociated process thread 126 a, currently loaded into bubble memory120, has been passed to the computer's CPU 24 and executed. At thispoint the triggering process is now running.

FIG. 4C depicts an Active State configuration of the computer at a pointafter that of FIG. 4B, at which point a connection to the Internet 14has been established by the triggering process 126 a (e.g. InternetExplorer browser), which is now running in memory 120. Data generated bythe running process 126 a and stored locally are isolated to bubblestorage 100 a by the IUE driver set 300.

FIG. 5A, illustrates a subsequent condition where additional processes130 a & 130 b, each having a IUE context, have loaded into bubble memory120. In this example, the processes 130 a & 130 b are derived from anexternal data source such as the Internet 14. If one of the processes130 a attempts to write to the computer's native data storage 26, thedriver set 300 redirects the write request to bubble storage 100 a.

FIG. 5B depicts a configuration of the computer running the present IUEat a point where the downloaded modules in bubble memory 130 a, 130 bare attempting to write to the systems data storage at paths common to atypical installation of the Windows operating system (e.g. C:\%systemfolder%\system32). However, all write requests originating from aprocess 130 a 130 b in bubble memory 120 are transparently redirected toa like path within bubble storage 100 a (e.g., %BUBBLE_DEV%:\%systemfolder%\system32) by the driver set 300.

FIG. 5C depicts a configuration of the computer running the present IUEat a point in its shut-down process, where the user has logged-out ofthe IUE environment, causing the connection to the Internet 14 to close,all processes 130 a 130 b 126 a running in the bubble memory 120 to beclosed and bubble memory 120 to be killed. However, any write requestsredirected to bubble storage 100 a by the driver set 300 during thesession remain isolated in bubble storage 100 a, unless otherwisedeleted, (e.g., by a “clean-up” function, virus scan, manually, etc.).

FIG. 5D depicts a configuration of the computer running the present IUEat a point in its shut-down process where the IUE data storage space(bubble storage) 100 a is unmounted by the driver set 300 and appears tothe operating system to be configured as a single flat file 100 storedon a data storage device 26.

FIG. 6 is similar to FIG. 4C, but depicts an Active State configurationof the computer 20 on a subsequent initiation of the IUE environment. Inthis configuration, when the stored IUE data space 100 is mounted by thedriver set 300, expanding it to a block device file system 100 a typicalof personal computers. The block device file system 100 a contains thedata 126 a 130 a written to it in previous IUE sessions. This conditionillustrates the persistence and availability of certain data created ina previous IUE session.

FIG. 7A depicts a configuration of the computer running the present IUEat a point in the active state where a module containing a trojan typeof malware 130 c (malicious code) has been downloaded into bubble memory120, and copied into bubble storage 100 a (as data 130 c) prior to itsexecution.

FIG. 7B depicts a configuration of the computer 20 running the presentIUE at a point in the active state where malware data 130 c in bubblestorage 100 a containing a trojan is called from bubble storage 100 a,loaded as a process 130 x in bubble memory 120 and executed. Onexecution, the trojan attempts to write to a primary system file/memory(e.g., C:\%systemfolder%\system32, and the system registry), but insteadis caused by the driver set 300 to write to bubble storage 100 a at likepaths 100 x & 116 x (e.g., %BUBBLE_DEV%\%systemfolder%\system32, and theIUE registry implementation).

FIG. 7C depicts a configuration of the computer 20 running the presentIUE application at a point in its shut-down process where the user haslogged-out of the IUE environment, causing the connection to theInternet 14 to close, all processes 130 x 126 a running in the bubblememory 120 to be closed and bubble memory 120 to be killed. However, anywrite requests redirected to bubble storage 100 a by the driver set 300during the session, remain isolated in bubble storage 100 a, unlessotherwise deleted (e.g., by a “clean-up” function, virus scan, manually,etc.).

FIG. 7D is a block diagram depicting an Active State configuration ofthe computer 20 at a point on boot-up after a IUE session such asdepicted in FIG. 7C has been previously run on the computer 20. In thiscase, when bubble storage 100 a is mounted, it contains the data 126 a,130 c & 116 x written to it in the previous IUE sessions, including thetrojan malware 130 c (unless the file was identified as malicious andeliminated by the cleanup function at the close of the prior IUEsession). However, because the malicious files or data 116 x created bythe trojan were isolated in bubble storage 100 a, where they were notexecuted by the reboot or upon mounting of bubble storage 100 a.

FIG. 8 shows a system in accordance with one embodiment of theinvention. The system includes an authentication module (described inFIG. 11), an environment handler (described in FIG. 12), a JobObjectManager (described in FIG. 10), a user database (described in FIG. 12),a NDIS hook (described in FIG. 14), an execute hook (described in FIG.9), a system call hook (described in FIG. 15), a file system filterdriver (FSFD) (described in FIG. 13), and a block device driver(described in FIG. 16). The block device driver and the FSFD areconfigured to interface with the flat file. Further, the execute hook isconfigured to interface with the executable. Finally, the executableimage is configured to interface with the execute hook and the systemcall hook.

FIG. 9 show a flowchart in accordance with one embodiment of theinvention. The following discussion outlines pseudo to implement theflowchart shown in FIG. 9 in accordance with one embodiment of theinvention.

Hook ShellExecute calls

Record process and affiliate parameters

Get pointer to a hash that defines the systems execution context1state .. . Check for context

EnvironmentHandler(NULL, NULL, . . . , . . ChkHash, . . . , . . . )

If no context hash1pointer exists

-   -   AuthService( ) Call authentication service and await return . .        .    -   if return(UserAuthenticated, UID, HashPointer)        -   if UID==[0] Super User            -   //Continue win32 normal ShellExecute processing            -   EscapeHook        -   else            -   call StartRestrictedProc(NULL, Create, NULL,                Process:parameters)        -   else return(AuthenticationFailure, NULL, NULL)        -   terminate ShellExecute call            -   exit silent    -   else if context hash1pointer exists        -   read hash            -   if UID==0                -   EscapeHook Continue normal Execute processing            -   else                -   call StartRestrictedProc(NULL, Add, NULL,            -   Process:parameters)    -   else if hash or pointer is corrupt1sta1e        -   return error        -   exit.

FIG. 10 show a flowchart in accordance with one embodiment of theinvention. The following discussion outlines pseudo to implement theflowchart shown in FIG. 10 in accordance with one embodiment of theinvention.

StartRestrictedProc(pointer, Create|Add process, process, process:parameters)

Define JobObject parameters: Security Descriptors, etc. . .

Receive JobObject management request

Get process/parameters to load for execution

if request format is munged

return error message

exit

else if

new job object is requested

-   -   EnvironmentHandler Check for haswpointer . . .        -   if hash1pointer exists            -   return an err message “A Job Object Environment already                exists” exit        -   else            -   CreateJobObject                -   MaxIdleTimeCounter=n(! StartIMaintain a proc Idle                    time clock!)                -   AssignProcessToJobObject                -   Return error message if failure “Cant Create Job                    Environment”        -   else if add process to object is requested            -   EnvironmentHandler                -   if hash1pointer exists                -    AssignProcessToJobOject( )                -   else return err message “There is no current Job                    Object Environment”                -   exit    -   else if last process in job quits, call EnvironmentHandler        -   destruct JobObject            -   EnvironmentHandler( ) Destruct Environment.

FIG. 11 show a flowchart in accordance with one embodiment of theinvention. The following discussion outlines pseudo to implement theflowchart shown in FIG. 11 in accordance with one embodiment of theinvention.

If request for auth

set authentication counter (maybe 3 try's before auth exits . . . )

display authentication window (user:password)

-   -   UserAuth( ) Check user:password combination against aflat        (txt)Jile    -   if Authenticated (U1D:PASSWD match)        -   If UID==0 //Super User/Admin        -   //Request demi environment creation from Environment Handler        -   EnvironmentHandler(UID, NULL, , . . , CreateHash, NULL,            NULL, NULL)        -   If return is ‘success’            -   return (‘UserAuthenticated’, HashPointer) to requestor                -   (ShellExecute Hook)    -   else    -   //Request environment creation from Environment Handler        -   EnvironmentHandler(UID, NULL, . . . , . . , . , InitEnv,            NULL)        -   If return is ‘success’            -   return (‘UserAuthenticated, HashPointer’)    -   if Authentication fails        -   if AuthCounter >0            -   display failed auth/retry authentication window            -   decrement counter        -   else if AuthCounter <=0            -   return auth failure            -   exit.

FIG. 12 show a flowchart in accordance with one embodiment of theinvention. The following discussion outlines pseudo to implement theflowchart shown in FIG. 12 in accordance with one embodiment of theinvention.

EnvironmentHandler (

UID: Numerical ID mapped to User-Name

User-Name: Users Authenticated SUES Environment name.

Hash-Perams: Colon separated parameters list: UniqueID:DivePath . . .

ChkHash: Bool; Does a hash/pointer already exist?

CreateHash: Only Create Hash, don't mount drives, etc. . .

GetPointer: Request a pointer to the current users hash.

InitEnv: Create a new environment.

DestructHash, Destroy current environment.

(The Hash is % UID%:% VIRTUAL-DRIVE-LETTER%, where thevirtual-drive-letter is collected from the win32check for available volletters function)

Maintain Subscription to File System Filter Driver

If request to check for hash

ChkHash( )

-   -   if hash:pointer exist in user db and pointer is valid        -   return 0    -   else        -   return 1            If request to create new hash

if ChkHash( ) Does hasWpointer exist?-ifyes . . .

-   -   return an err message “A Job Object Environment already exists”    -   exit

else

-   -   GenerateHash //Create a unique hash using authenticated UID as        seed    -   return hash    -   MmapHash //Place hash in memory    -   return pointer    -   Appenduserprofile //Concatenate the authenticated users profile,        in the user data base, with the newly generated hash/pointer        (UID: USER-NAME: PASS WD becomes UID: USER-NAME:PASS WD: %HASH%:        %POINTER)    -   return pointer        If request to create new environment

if ChkHash( )//Does haswpointer exist?

-   -   return an err message “A Job Object Environment already exists”        -   exit

else if ChkVol( )// See if the virtual disk indicated in the UID hash ismounted;

-   -   return error message “A volume is already mounted for this        environment”        -   exit

else

LoadDriver Set

-   -   if failure    -   return error message “File System Driver failed to load”    -   call ‘Destruct Environment’

!Open handle to File System Filter Driver! ‘Subscribe’

GetAvailableDriveLetter

if success

-   -   Appendprofile Concatenate the authenticated users profile, in        the user data base, with the returned drive letter (UID:        USER-NAME:PASSWD becomes UID: USER-NAME: PASS WD: DRIVELETTER:)

else

-   -   return error message “Cant get volume map”    -   exit        AppendUserProfile        Concatenate the authenticated usersprofile, in the jlut (txt)        data base, with the newly generated hash/pointer (UID:        USER-NAME:PASSWD: DRIVELETTER becomes        UID: USER-NAME: PASS WD: DRIVELETTER: :%POINTER%)        return pointer        Mount(GetVolName)//Mount the loopback FS using VolName/Label        if volume is successfully mounted

return 0

else

return error message “Mount Volume failed”

Destruct Environment

exit

If request to destruct environment

if ChkHash( ) Does hasWpointer exist?

if ChkVol( ) See if the virtual disk indicated in the UID hash ismounted;

-   -   UnMount( )    -   if volume is successfully unmounted        -   return 0    -   else        -   return error message “Un-mount Volume failed”        -   exit

else

-   -   return error message “No volume mounted for this environment”        UnloadHash Remove the hash from memory    -   If fails        -   Return error message

RmPointer Remove the volume:pointer string appended to the users profile(in the Jlat [.txt file] data base . . . )

-   -   if fails        -   return error message

UnloadDriver Set

-   -   if fails        -   return error message            else

return error message “No Environment Exists”

If request to GetHashPointer

if ChkHash( )

return pointer

else

return error

exit

FIG. 13 show a flowchart in accordance with one embodiment of theinvention.

In step 1, the I/O manager creates an IRP for any given operationneeding file system I/O processing. It fills the stack locationcorresponding to the driver that is at the top of the layer (in thiscase our File System Filter). In step 2, the File System Filter, onreceiving an IRP, does any processing needed to fulfill the current SUEZfilter rules. In step 3, the File System Filter then returns the IRP tothe I/O manager, copying its stack to the lower drivers stack location.In step 4, the I/O manager passes the IRP on to the driver below it inthe layer order (in this case, the File System Driver). In step 5, thelower level driver now processes the IRP; using its own stack. In step6, the lower level driver (FSD) returns the IRP back to the I/O manager.The I/O manager then releases any resource allocated to the IRP.

FIG. 14 show a flowchart in accordance with one embodiment of theinvention.

The following discussion outlines pseudo to implement the flowchartshown in FIG. 14 in accordance with one embodiment of the invention. Inone embodiment of the invention, the NDIS Hook intercepts IP packets atthe NDIS (Network Device Interface Specification) layer using a customdriver, for example, SUEZNDIS.VXD or SUEZNDIS.SYS and at the SPI(Service Provider Interface) layer using, for example, a SUEZNDIS.DLL.In one embodiment of the invention, each intercepted packet is checkedagainst the filtering rules that define what kind of traffic is allowedto pass. Allowed incoming packets are forwarded to the TCP/IP stack (notshown) and the networking applications (not shown). Similarly, allowedoutgoing packets are sent out on the network interface. In oneembodiment of the invention, the rules describing the aforementionedfiltration are provided as meta data.

FIG. 15 show a flowchart in accordance with one embodiment of theinvention. The following discussion outlines pseudo to implement theflowchart shown in FIG. 15 in accordance with one embodiment of theinvention. In step 1, the application executes a registry related systemcall. In step 2, the WINDOWS® system call handler looks up the kernelfunction corresponding to the system call, which SUEZ has replaced withits own function. In step 3, SUEZ calls its system call hook function.In step 4, SUEZ invokes the original handler. In step 5, SUEZ invokesits environment specific registry handler. In step 6, the environmenthandler prescribes filter metadata, and periodically obtains logstatistics.

System Overview

Turning now to FIG. 16 there is provided a schematic illustration of thesystem environment wherein the described software system is operating,referred to as system 500 and representing a preferred embodiment of thepresent invention upon installation and initialization on the Hostcomputer system. The system 500 includes seven principal componentswhich comprise the preferred embodiment of an Isolated User Environment(IUE) software:

a) The Execution Hook component, which intercepts all system calls toload an executable image and tests the execution requests for anassigned User context. This testing allows credential based assignmentof processes to an alternate method of process creation to that nativeto the Host computer system. Additionally, the Execution Hook is thetriggering mechanism for the initiation of new Isolated UserEnvironments.

b) The Job object module, which provides an alternative process creationmechanism that allows the IUE to create a job with specific securitydescriptors and then assign User processes and their children to thisjob for creation; this assignment facilitates starting User processes ina restricted state, allowing the Environment handler to prescribegranular control over the credentials, memory allocation, IPC andgeneral functionality assigned any User processes. All processesassigned to a User job are definable by a context representing thisassociation and are effectively jailed within the file system namespaceallocated to User's isolated User environment by this context due to itsbeing honored by the complementary software components of the presentsystem.

c) The System Call Hook, which provides a virtual registry, private tothe isolated User environment, by selectively redirecting registry callsassociated with a Users context to a virtual registry within theisolated User environment. The IUE System Call Hook has its interceptionfunctions run in lieu of the Host computer systems original system callfunctions simply by inserting pointers to the IUE replacement functionswithin the Windows system call array. After the IUE System Call Hook hasexamined the parameters an application, requesting registry I/O, passedto a system call, it tests these parameters against a set of filterrules prescribed by the environment handler to determine whether the I/Omust be redirected to the isolated User instance of the Windowsregistry. If the original system call request is not of User context,the IUE System Call hook invokes the Host system call it replaced. Whencontrol returns to the IUE System Call Hook from the Host system call,the IUE System Call functions can optionally still examine the returnstatus and pass control to the requesting application. FIG. 15demonstrates this process. System call indexes can change betweendifferent releases of Windows, but the method the preferred embodimentuses to determine indexes is version-independent.

d) The Block device driver, which is a file system driver component formounting and un-mounting a flat file as a block device. This facilitatethe isolation of the User's isolated file system from the Host filesystem. In the preferred embodiment this driver is called upon, at IUEinitialization, to mount a specific isolated User file system by theenvironment handler. The call for destruction of an isolated Userenvironment results in a subsequent call from the environment handler tounmount the isolated User file system.

e) The File System Filter Driver (FSFD), which facilitates presentingthe file system namespace of an IUE to its associated User and Usercontext processes as a combination of the Host computers file systemnamespace and that of the Users isolated file system. Control of whatobjects from the Host computers file system are included in this mergerof namespaces is controlled by User credentials and their associatedmetadata, prescribed by the environment handler. The FSFD interceptsrequests targeted at a file system or another file system filter driver.By intercepting the request before it reaches its intended target, theFSFD extends or replace functionality provided by the original target ofthe request. All I/O requests made by any process with User context areproxied, allowing processing of all such I/O(read|write|modify|delete|copy, etc) to be performed in lieu of normalprocessing. This includes the transparent redirection, of select filesystem requests, to the User's isolated file system.

f) The NDIS driver, which isolates User context requests for networkconnectivity to that Users IUE. To facilitate isolating User networkinteractions to the IUE, the preferred embodiment exports one or morevirtual adapters, bound to Users IUE, to which overlying protocols canbind. To a protocol driver, a virtual adapter exported by theintermediate driver appears to be a physical NIC. This allows an IUE tobe bound to a MAC and IP address removed from that of the Host computersystem. Additionally, the NDIS hook intercepts IP packets at the WindowsNDIS (Network Device Interface Specification) layer; each packet ischecked against the filtering rules that define what kind of traffic isallowed to pass. Allowed incoming packets are forwarded to the TCP/IPstack and the networking applications. Similarly, allowed outgoingpackets are sent out on the network interface.

g) The Environment handler component, is responsible for creating anddestructing User specific IUE's as needed, however, to facilitate tyingall described IUE software components together, the Environment Handlerprovides environment management services for all the components of thepreferred embodiment by revealing an administrative configurationinterface to system administrators. It facilitates the definition of therules and general configuration data that defines the operation of thepresent system. User authentication and credentials for all softwarecomponents, prescribing filter metadata and periodically obtaining logstatistics or metrics from all IUE software components are all under theenvironment handlers jurisdiction. Additionally, the environment handleroperates as a proxy to facilitate interconnection of all components ofthe IUE, tying all the described components into a single source forauthentication, filter and parameter metadata, credential discovery,system state and general configuration.

FIG. 16 presents a high level flow diagram of the IUE componentsoperation. The preferred embodiment providing isolation of all Userexecution and I/O operation from the Host computer system 500. TheExecution Hook component intercepts system calls requesting processexecution. All such calls are tested for a User context previouslyassigned by the IUE software. If a user context is present, theenvironment handler is queried to determine how to operate on thecurrent request. If the request is determined to be in the context of aUser with a currently initialized IUE, then the process is passed to theexisting User associated job object for creation. If no User context ispresent in association with a request for process creation, theenvironment handler is interrogated for authentication. Upon return ofauthentication, a context is assigned reflecting the credentials of theauthenticated operator. If the User has administrative credentials, anadministrative context is set and the request for process execution ispassed to the Host systems native process creation mechanism. If theUser credential is not privileged, the environment handler initiates thecreation of a IUE to which to bind the User. This Isolated UserEnvironment initialization consists of the creation of a Job Object,with credentials specific to User (as prescribed by the environmenthandler during its creation of the User Job Object), to which all Userprocesses can be assigned for creation and the mounting of a flat fileas a block device by the Block Device Driver providing an isolated Userfile system, additionally, the initialization of the File System FilterDriver (FSFD), System Call Hook and NDIS drivers, having been prescribedby the Environment Handler appropriate filtering metadata reflecting thecredentials of the User for which the environment is being created andfinally, any pre-processing specifically required for User or generallyrequired by the software are processed by the Environment handler.

Once an IUE has been initialized for User by the Environment Handler,all subsequent process creation requests are assigned to the User JobObject component and loaded suspended. Once assigned, an alternativeprocess creation mechanism defines specific memory restrictions andsecurity descriptors binding all User processes and their children, thenthe process is released from its suspended state for execution in theIsolated Execution Environment (IEE) created by the Job Object.

Once User processes are restricted to the Isolated Execution Environment(IEE), binding them within the User's IUE, they are unable to seeobjects outside their IUE, as defined by the credentials prescribed bythe environment handler. Effectively, they operate as normal, though thefile system namespace and process object namespace revealed to them byFSFD and IEE is restricted to the IUE namespace or some subset of theHost computer systems namespace in combination with the that of theUsers IUE.

User processes making I/O requests targeted at a file system or anotherfile system filter driver are intercepted by the FSFD for examinationand potential modification. By intercepting the request before itreaches its intended target, the filter driver extends or replacefunctionality provided by the original target of the request. All I/Orequests made by any process owned by User are proxied, allowingprocessing of all such I/O (read|write|modify|delete|copy, etc) to beperformed in lieu of normal processing. This includes the transparentredirection of select file system requests to User's isolated User filesystem, as well controlling object visibility or access by object type,credentials, location, etc. By mirroring the Host computers native filesystem hierarchy and implementing granular FSFD redirection filteringrules, the preferred embodiment can create a merged view of the Hostcomputer systems process object and file system namespace for exposureto User processes. An example of this would be to allow User access toparticular directories on the Host file system, all other directoriesbeing mirrors of the Host file system but resident on the isolated Userfile system. Restarting the Host computer systems shell under the Userscontext upon initiation of the IUE results in the graphical presentationof the User namespace presented by the computer system, such as thedesktop, file explorer etc, to be a reflection of the users namespacemerged with whatever objects have been configured for revelation to theUser by the FSFD.

An application's configuration data is crucial to its proper function.The windows registry provides programs an interface to system andsoftware configuration data. To facilitate this functionality, whilestill abstracting the Host computer system from processes belonging toan IUE, the preferred embodiment implements a System Call Hook tointercept and filter registry I/O, protecting the Host computersconfiguration data. User processes making I/O requests to the Windowsregistry structure may be making calls to edit cells in volatile memory,thus the need for a redirection system in addition to the FSFD. Suchsystem call requests are tested for User context by the System Call Hookcomponent and filtered based on rules prescribed by the EnvironmentHandler. Because the Windows System Service functions are stored in asystem service dispatch table within the kernel, the IUE System CallHook driver is able to hook a system service by saving the address of afunction from Host's native array and replacing the array entry with theaddress of the IUE hook function. Once the IUE is installed on a system500, any invocations of the hooked system service get diverted to theIUE drivers function. Here the call is examined for an association to aUser context. If the call is found to originate from a User contextprocess it may be modified and the registry request diverted to aregistry within the isolated User environment. The IUE registry may be amirror of the host systems registry hive or some subset there of,optionally, a read-first operation can be performed that looks to theUser registry for requested key's before examining the Host computersystems native registry for the requested I/O.

Commonly, User processes will request connectivity to an attachednetwork, such as the Internet. To isolate such interactions to the IUE,this embodiment of the present invention utilizes an NDIS driver thatexports a virtual adapters specific to the Users IUE. This allows an IUEto be bound to a MAC and IP address removed from that of the Hostcomputer system. Additionally, the NDIS hook intercepts IP packets atthe Windows NDIS (Network Device Interface Specification) layer; eachpacket is checked against the filtering rules that define what kind oftraffic is allowed to pass. Allowed incoming packets are forwarded tothe TCP/IP stack and the networking applications. Similarly, allowedoutgoing packets are sent out on the network interface.

Use Case

The following Use Case(s) are used primarily to capture the high leveluser-functional requirements of the SUEZ system. This section provides adescription of each section in the use case template.

Actor: An actor is a person or other entity external to the softwaresystem being specified who interacts with the system and performs usecases to accomplish tasks. Different actors often correspond todifferent user classes, or roles, identified from the customer communitythat will use the product.

Description: A brief description of the reason for and outcome of thisuse case, or a high-level description of the sequence of actions and theoutcome of executing the use case.

Preconditions: List any activities that must take place, or anyconditions that must be true, before the use case can be started.

Postconditions: Describe the state of the system at the conclusion ofthe use case execution.

Normal Case Provides a detailed description of the user actions andsystem responses that will take place during execution of the use caseunder normal, expected conditions. This dialog sequence will ultimatelylead to accomplishing the goal stated in the use case name anddescription.

Alternative Case Documents other, legitimate usage scenarios that cantake place within this use case. States the alternative flow, anddescribes any differences in the sequence of steps that take place.

While the above description contains many specifics, these should not beconstrued as limitations on the scope of the invention, but rather asexemplifications of one or another preferred embodiment thereof. Manyother variations are possible, which would be obvious to one skilled inthe art. Accordingly, the scope of the invention should be determined bythe scope of the appended claims and their equivalents, and not just bythe embodiments.

1. A method for securing a computer system, comprising: monitoring anoperating system executing on a processor in the computer system;trapping, in response to the monitoring, a process system call toexecute a program, wherein the process system call originated in a hostexecuting in the computer system; responsive to the trapping:determining whether the process system call is associated with a usercontext; in response to determining that there is no user contextassociated with the process system call creating the user context for auser that initiated the process system call, creating an isolated userenvironment (IUE) in the computer system, and binding the user contextto the IUE, wherein, after the binding, subsequent requests associatedwith the user context are restricted by the IUE, wherein creating theIUE comprises: allocating memory and persistent storage for the IUE inthe computer system, creating a user job object associated with the userand comprising security descriptors, wherein the user job object isassociated with the IUE, wherein user processes associated with the userjob object are restricted by the IUE based on the security descriptors,exporting a virtual adaptor from the IUE to the host, wherein thevirtual adaptor is associated with a Media Access Control (MAC) addressand an Internet Protocol (IP) address; and wherein the IUE is associatedwith: a file system filter driver (FSFD) configured to redirectInput/Output (I/O) calls originating from the IUE to the persistentstorage, and a network interface/NDIS hook component configured tocontrol, using the virtual adapter, network traffic originating from theIUE to network devices external to the host and destined for the IUEfrom network devices external to the host; after creating the IUE,loading an executable image corresponding to the program into the IUE;and executing the program using the executable image in the IUE usingthe processor, wherein the IUE enables a user to provide input to theprogram during execution, wherein a user process executing the programis associated with the user job object, wherein execution of the programis restricted based in part on the user job object, and wherein duringexecution of the program in the IUE at least one packet is sent, usingthe virtual adaptor, from the IUE to a network device external to thehost.
 2. The method of claim 1, further comprising: responsive to theexecuting, issuing an I/O call from the IUE to a file system of thehost; and redirecting, by the FSFD, the I/O call to the persistentstorage, wherein the persistent storage comprises a file system of theIUE.
 3. The method of claim 2, wherein a hierarchy of the file system ofthe IUE mirrors a hierarchy of the file system of the host.
 4. Themethod of claim 2, wherein the FSFD is configured to limit the portionsof the file system of the host which processes executing in the IUE mayaccess.
 5. The method of claim 1, further comprising: responsive to theexecuting, issuing an I/O call from the IUE to a registry of the host;and redirecting, by a system call hook component, the I/O call to thepersistent storage, which includes a registry of the IUE.
 6. The methodof claim 5, wherein the registry of the IUE is a mirror of the registryof the host.
 7. The method of claim 5, wherein the system call hookcomponent is configured to query the registry of the IUE prior toquerying the registry of the host when locating a registry key.
 8. Themethod of claim 1, further comprising: responsive to the executing,storing data in the persistent storage; after executing the processsystem call, closing the IUE; and responsive to closing the IUE,terminating all processes executing the IUE, deallocating the memory andunmounting the persistent storage.
 9. The method of claim 8, furthercomprising: creating a new IUE after closing the IUE, wherein the datain the persistent storage is accessible through the new IUE.
 10. Themethod of claim 1, wherein the process system call is associated withthe user, wherein the persistent storage comprises a file system for theuser and wherein the IUE comprises a file system block device drivercomponent configured to mount and unmount the file system for the user.11. The method of claim 10, wherein the file system for the user isstored as a flat file in the persistent storage after the IUE is closed.12. The method of claim 1, wherein the process system call correspondsto a call to open a web browser and access a website external to thehost via the web browser.
 13. The method of claim 1, wherein the host isassociated with a first TCP/IP stack and the IUE is associated with asecond TCP/IP stack, wherein the first TCP/IP stack is distinct from thesecond TCP/IP stack.
 14. The method of claim 1, wherein the processsystem call is associated with the user job object and wherein jobobjects not associated with the IUE are hidden from the restrictedprocess.
 15. The method of claim 1, wherein the IP address associatedwith the virtual adapter is distinct from an IP address associated witha physical network interface connected to the host.